Repository navigation
Conversation
A component declares what it needs from whatever binds its file, in `params`: an exchange's two models (from sim-nam's exchanges row), a mover's or GNC's (passed down from the exchange), SPC's and SPCA's flow package (from SSM's row), and OBS's target (its parent). An fk names one with `param`, a cellid's `model` names one instead of "1"/"2", and a `when` may test one (MVR's MODELNAMES is set exactly when model2 is). The rules exchange_models and ssm_package go; no_advanced_transport takes the part of ssm_package that isn't about the binding. OBS's obstype names one of its target's observation types, under the reserved key set name `observations`. Co-Authored-By: Claude Opus 5.5 <[email protected]>
A component's `params` is now a signature, `{type, rule}`, and the file
that binds it passes them in `args`, each naming a column of the binding
row or one of the binder's own parameters. Drops `from` and its three
source forms. Every exchange declares `model1`/`model2`.
OBS needs no parameter: its target is the file's owner, which
cross-component fks already resolve against. Drop obstype's fk and the
reserved `observations` key set with it, and the fk form that picked a
key's instance by a rule alone, which nothing uses now.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Adds a Bindings section: terms (binding, parent, binding row, reference, context), every kind of binding in MODFLOW 6 with its input, and parameters as the cases that need them. Moves Parameters into it, and uses the same terms in the schema docstring and migration comments. Co-Authored-By: Claude Opus 5.5 <[email protected]>
Scope here is the programming sense, and so are the spec's other uses: a dimension's scope says whose scope it's in, and a scoped key is a qualified name. Co-Authored-By: Claude Opus 5.5 <[email protected]>
Bindings build the tree that references resolve in, so the Bindings section now comes before Primary and foreign keys, and Parameters, which uses keys, key sets and rules, is its own section after Rules. Terms says how a binding differs from a reference, with the exchanges row as one that holds both. The parent and component attributes now say what a binding is. Co-Authored-By: Claude Opus 5.5 <[email protected]>
"Binding row" read as a row whose job is binding, but the binding is one field among keys, references and data: the exchanges row also refers to its two models. An argument names a sibling of the binding with an fk. The validator's message says "sibling column" to match. Co-Authored-By: Claude Opus 5.5 <[email protected]>
The spec said no binding knows a transport model's flow model, since no exchange binds SSM. But mfsim.nam binds the transport model and holds the pairing, in an exchanges row rather than the binding's siblings. An argument can name only a sibling or a parent's parameter, which is why flow_model is a rule. Co-Authored-By: Claude Opus 5.5 <[email protected]>
A binding is a field in the parent's input naming a subcomponent's input file. It introduces what it names; a reference names something that exists without it, and resolves by lookup in the tree. Co-Authored-By: Claude Opus 5.5 <[email protected]>
Terms now defines parameters and arguments. Scope lists sim-tdis alone: sim-nam is every component's ancestor already, and no fk targets sim-tdis; it's in scope for its nper dimension. Co-Authored-By: Claude Opus 5.5 <[email protected]>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rethink #406, #407. The basic problem is that MF6 components refer to each other in various ways:
mfsim.namEXCHANGES, and that's it. But some reference info is split across two files, e.g.mfsim.nambndnonumbers the bounds of a flow package, and only SSM says which oneThe spec/schema has been accruing a bunch of ad hoc machinery to represent all this, no bueno. There is theory we can lean on, of course it comes from Knuth: attribute grammars. An attribute grammar attaches information to the nodes of a tree, so you can define semantics in a controlled way. But that's a bit abstract, so probably best reserved for internal docs. Rewrite the DFN spec and schema in analogous but more familiar concepts
This can all be thought of as a function call, where parametrized components let you send information through bindings down the tree.
To make this concrete, a child DFN (e.g. exchange) can declare a "signature" which a parent DFN (e.g. simulation) can "call". So in
mfsim.namexchanges blockA parameter is passed along a binding, from parent to child, but what it describes can point anywhere the parent can see: e.g.
gwf_1is the exchange's sibling, not its ancestor. This is like lexical scoping: references resolve against the component itself, its parameters, its ancestors (anything above it), or a simulation-scoped singleton package like TDIS. So a parameter is a way to move a non-hierarchical reference down a hierarchical edge. A child can point sideways using a name resolved by its parent.